| Review 1 | |
| PC member | Antranig Basman |
| Overall evaluation |
I enjoyed this paper and its erudite wander through the space of our notational history. The
modernist/postmodernist split is interestingly motivated, and could be aligned with other
similar distinctions, for example the author’s own “compatibilism” which was part of last
year’s submission. There could also be an alignment and perhaps even a contrast with Noble
and Biddle’s concepts of postmodern
programming (TR, 2002) and Bruno Latour’s attempts to reconnect denaturalised worlds
in his 1991 We Have Never
Been Modern. Another important connection would be with that of an integration domain (Kell, 2009) - it seems clear that the embedded sublanguage that we see establishing relationships in Figure 1 forms such a domain, relating together graphical elements in a computationally non-intensive way. Tighter focus on the concerns of an integration domain would allay the problems which the authors allude to at the end of section 2.1 where they fear the risks of undermining the portability of the resulting interactive artefact by embedding unhelpful dependencies on a particular mode of computation. I like the presentation of workflows leading from static VG tools towards the VVE. A dimension missing from so many treatments is an explanation of how some clever (post)modern system is intended to coexist with pre-established authoring workflows. The references to the incremental computing literature are to heavyweight systems with rigorous entry requirements, and I think the system the authors describe could benefit more easily from commodity reactive systems of the kind I describe in this year’s submission, perhaps with some malleable properties mixed in. The world of self-raising diagrams is going to be a postmodern, disorderly one with nodes appearing and disappearing at the behest of multiple authors, and commodity reactivity will likely be a better fit for the world of layout-affecting mutations that the authors are appealing to. Another missing dimension from the analysis is considering the reverse dimension to “self-raising” which I guess would be called “self-flattening” - how is a “raised” artefact meant to continue to enjoy beneficial properties if it is round-tripped back to the “flat world” of diagrams that gave birth to it? There are analogies here with how richly structured data is meant to continue to participate in ecosystems that have ingested relatively unstructured representations such as CSV. This raises issues of alignment which in that terrain can be addressed with alignment-promoting tools such as the CSV diffing tool daff, and similar tools for establishing alignment amongst SVG structures will doubtless be necessary. A quick Google for “svg diff” doesn’t turn up anything particularly recent or encouraging, but the authors are not going to be able to deliver on the goals of “Two visually identical diagrams should behave identically” without the help of tooling which is capable of straightforwardly determining a metric that determines to what extent two diagrams are indeed visually identical. I would like to see more of a connection between this work and the 2nd author’s work on malleable code projections via the Lorgnette system, which I believe embodies the Horowitz & Heer for the notion of a rich notation (the Lorgnette UIST paper includes a reference to the Horowitz & Heer 2023 paper but does not seem to cite it!). I believe the “raising” operator would be best positioned as a projected notational richness which can be used to imbue the pre-existing static diagram. It is important to consolidate references to these many, somewhat aligned ontologies that we find in the literature so it is possible to build a coherent overview of the relationships between these many patterns of work. |
| Review 3 | |
| PC member | Orion Reed |
| Overall evaluation |
This submission proposes treating SVG diagrams as a substrate for notational freedom. Rather
than building bespoke drawing, programming, and storage infrastructure (the "Modernist"
approach), the authors exploit SVG's de-facto ubiquity across editors and browsers, reducing the
problem to interpretation and transformation of vector graphics. They sketch a "Vector Vision
Engine" (VVE) that extracts spatial relationships from SVG, executes embedded code, and —
aspirationally — processes user-defined ad-hoc notations. Static diagrams function as executable
documentation; "self-raising" diagrams bootstrap themselves into interactive
applications. The paper is well written and the core rationale is sharp: the postmodern move of augmenting a ubiquitous data format with the "missing piece" of computational interpretation, rather than reinventing drawing and editing from scratch, is compelling and well-articulated. The BitsTable example — a hand-drawn TCP packet header diagram that compiles to a C struct — is shows tangible value with minimal infrastructure. The framing through the modernist/postmodernist distinction is applied well here. The historical observation that early programming used diverse diagrammatic notations, and that textual lock-in was a contingent consequence of teletype interfaces rather than an intrinsic property of computation, is a nice motivating move. This approach shares a strategic logic with other postmodern efforts in the workshop — including Allio (myself and Shank), which similarly augments existing ubiquitous infrastructure (accessibility APIs) toward substrate-like properties rather than designing from scratch. On the question posed at the end of the paper — whether SVG is already a substrate — I think the answer is no, but the category is worth articulating. In my own work I used "proto-substrate" to describe systems that occupy the right ontological position (ubiquity, shared vocabulary, wide coverage) while missing key computational properties. This submission gives further evidence that such a category may be productive. I have several questions and concerns: The meta-notation layer — the mechanism by which users would define their own ad-hoc notations — is the core of the "notational freedom" claim, but it is marked as not yet implemented (VVE step 3), with step 4 described as highly unstable. I would have appreciated even a conceptual sketch of what defining a notation would look or feel like in practice. Would one draw a diagram containing both example instances and interpretation rules? Write JS in a Magic Red box that registers a spatial pattern? Without at least a mental model of this, it's difficult to evaluate whether the architecture can support the central claim. The VVE's "de-spatialize" step extracts relationships like containment and connector incidence from the SVG DOM. But CSS transforms (translate, scale, rotate) and SVG transform attributes can cause visual containment to diverge from DOM-structural containment. The paper doesn't mention this; does the prototype resolve computed positions, or does it operate purely on the DOM tree? For the "No Hidden State" principle — two visually identical diagrams should behave identically — this seems like it matters: should behavior track what the user *sees*, or what the DOM happens to encode? The "Magic Red" and "Magic Green" border-color conventions are pragmatic for prototyping, but they sit in some tension with the No Hidden State principle. A specific hex value (#D0021B) that is semantically meaningful to the VVE but appears as "just red" to a human viewer is, in effect, hidden state encoded in the view. What happens if a user picks a nearby shade? Can SVG accommodate this distinction through other means — custom data attributes, namespaced metadata — that would be invisible to rendering but explicit in the document structure? And if that is antithetical to the goal, then what means are there of disambiguating pieces of a notations' representation? On the discussion prompts: the authors ask whether advanced AI image perception would make VG substrates obsolete. I think the answer strengthens their case — vector graphics parsing is deterministic and inspectable, while vision models give probabilistic interpretations that are difficult to predict or debug. For a programming substrate, where users need to reason reliably about what their notation means, that difference seems fundamental. There is also emerging work on neurosymbolic programming languages that integrate probabilistic model-driven computation into symbolic frameworks, suggesting that AI perception could enrich a symbolic substrate's input layer rather than replacing the need for deterministic interpretation. The paper would benefit from engaging more directly with the design space it opens up. The self-raising diagram examples are exciting but modest — what about embedding richer computational models (dataflow, constraints, propagators) as notational elements within SVG? Could notations themselves ultimately be expressed as SVG diagrams that specify their own interpretation? These questions feel close to the surface but aren't explored, and I think they would make for productive workshop discussion. Overall, this is a strong submission that should generate productive discussion at the workshop. The postmodern strategy of targeting the interpretation gap in an existing ubiquitous format is well-motivated, the examples are concrete, and the design space it opens — particularly around user-defined notations and self-raising diagrams — is rich. I look forward to seeing the meta-notation layer develop. |
| Review 4 | |
| PC member | Pavel Bažant |
| Overall evaluation |
The article describes a specific postmodern approach to building a programmable substrate with
interesting properties like notational freedom (hybrid textual-graphical), interactivity, and
programmability. The idea is to take existing standards — specifically SVG and the web browser — as the data and computational substrates respectively, and, by combining them, to implement an interactive, programmable document system that allows one to combine graphical and textual program notation. What a marvelous hack! I wondered at which point adding more and more mechanisms to the interpreter makes the result modernist again, only to see this very point mentioned by the authors themselves. I think once we've identified the pure extremes of modernism and postmodernism, it will be interesting to combine those approaches in various ways. For example, design as a modernist, then adapt the result as postmodernist. Consider adding GRaIL to your examples of boxes and arrows-based programming systems — it seems quite advanced and predates the other systems you mention. I'd consider Boxer a hybrid system, despite the name. Regarding those hybrid systems, I'd like to mention that Mathematica allows advanced visual notation as part of textual expressions. SVG as a substrate has the following limitation: it cannot embed graphics into the text in contains, so it cannot nest free-form 2D notation (VG) and text recursively. Some of the other hybrid systems (e.g. the "state machines in Prolog" you mention) seem to have the opposite limitation: they can embed graphics in text, but not recursively. It would be interesting to discuss this notational non-recursiveness in some future work. A comment regarding bitmaps: SVG can contain bitmaps, so the bitmap usecases are in principle covered, too. (To the extent SVG editors support editing embedded bitmaps.) SVG in the browser vs. in a regular editor is analogous to code in the IDE vs code in Notepad. In this sense, your work highlights concepts and distinctions that are mostly experienced in the context of text-based programming, but turn out to be orthogonal to the text-graphical axis, which is very interesting. I wonder if the same kind of trick — parse lightly, run a standard initialisation that adds hooks to the original document, then run in a standard environment — can be used in purely textual substrates. Emacs and Oberon come to mind as specific examples. A comparison would be interesting. A nitpick: If appearance ("invisible DOM details do not change behaviour") is all what matters, what are the benefits of normalising to circles in-place? I guess the answer depends on what set of "standard editor affordances" we can assume. Your editor doesn't provide control over circle vs bezier, but another editor provides a separate DOM view, making "hidden DOM details" not hidden anymore. At some point you mention self adjusting computation. What kind of incrementality do you have in mind? In the absence of hidden state, isn't incremental computation "just" an optimisation of the reparse on every change approach? Overall, very interesting work! |